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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 
Abstract 


This document updates the handling of DirectoryString in the Internet 
X.509 Public Key Infrastructure Certificate and Certificate 
Revocation List (CRL) Profile, which is published in RFC 3280. The 
use of UTF8String and PrintableString are the preferred encoding. 

The requirement for exclusive use of UTF8String after December 31, 
2003 is removed. 
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1. Introduction 


At the time that RFC 3280 [PKIX1] was published, it was very unclear 
how international character sets ought to be supported. 
Implementation experience and deployment experience have made the 
picture much less fuzzy. This update to RFC 3280 aligns the document 
with this experience and the direction of the IETF PKIX Working 
Group. 


The use of UTF8String and PrintableString are the preferred encoding. 
UTF8String provides support for international character sets, and 
PrintableString preserves support for the vast bulk of the 
certificates that have already been deployed. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [STDWORDS]. 


3. Update to RFC 3280, Section 4.1.2.4: Issuer 
In Section 4.1.2.4, RFC 3280 says: 


The DirectoryString type is defined as a choice of 
PrintableString, TeletexString, BMPString, UTF8String, and 
UniversalString. The UTF8String encoding [RFC 2279] is the 
preferred encoding, and all certificates issued after December 31, 
2003 MUST use the UTF8String encoding of DirectoryString (except 
as noted below). Until that date, conforming CAs MUST choose from 
the following options when creating a distinguished name, 
including their own: 


(a) if the character set is sufficient, the string MAY be 
represented as a PrintableString; 


(b) failing (a), if the BMPString character set is sufficient 
the string MAY be represented as a BMPString; and 


(c) failing (a) and (b), the string MUST be represented as a 


UTF8String. If (a) or (b) is satisfied, the CA MAY still 
choose to represent the string as a UTF8String. 
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Exceptions to the December 31, 2003 UTF8 encoding requirements 
are as follows: 


(a) CAs MAY issue "name rollover" certificates to support an 
orderly migration to UTF8String encoding. Such 
certificates would include the CA’s UTF8String encoded 
name as issuer and the old name encoding as subject, 
or vice-versa. 


(b) As stated in section 4.1.2.6, the subject field MUST be 
populated with a non-empty distinguished name matching the 
contents of the issuer field in all certificates issued by 
the subject CA regardless of encoding. 


The TeletexString and UniversalString are included for backward 
compatibility, and SHOULD NOT be used for certificates for new 
subjects. However, these types MAY be used in certificates where 
the name was previously established. Certificate users SHOULD be 
prepared to receive certificates with these types. 


In addition, many legacy implementations support names encoded in 
the ISO 8859-1 character set (LatinlString) [ISO 8859-1] but tag 

them as TeletexString. TeletexString encodes a larger character 

set than ISO 8859-1, but it encodes some characters differently. 

Implementations SHOULD be prepared to handle both encodings. 


This block of text is replaced with the following: 


The DirectoryString type is defined as a choice of 
PrintableString, TeletexString, BMPString, UTF8String, and 
UniversalString. CAs conforming to this profile MUST use either 
the PrintableString or UTF8String encoding of DirectoryString, 
with one exception. When CAs have previously issued certificates 
with issuer fields with attributes encoded using the 
TeletexString, BMPString, or UniversalString, the CA MAY continue 
to use these encodings of the DirectoryString to preserve the 
backward compatibility. 


4. Update to RFC 3280, Section 4.1.2.6: Subject 
In Section 4.1.2.6, RFC 3280 says: 
The subject name field is defined as the X.501 type Name. 
Implementation requirements for this field are those defined for 
the issuer field (section 4.1.2.4). When encoding attribute 


values of type DirectoryString, the encoding rules for the issuer 
field MUST be implemented. 
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D4 


6. 


This block of text is replaced with the following: 


The subject name field is defined as the X.501 type Name. 
Implementation requirements for this field are those defined for 
the issuer field (Section 4.1.2.4). CAs conforming to this 
profile MUST use either the PrintableString or UTF8String encoding 
of DirectoryString, with one exception. When CAs have previously 
issued certificates with subject fields with attributes encoded 
using the TeletexString, BMPString, or UniversalString, the CA MAY 
continue to use these encodings of the DirectoryString in new 
certificates for the same subject to preserve backward 
compatibility. 


Since name comparison assumes that attribute values encoded in 
different types (e.g., PrintableString and UTF8String) are assumed 
to represent different strings, any name components that appear in 
both the subject field and the issuer field SHOULD use the same 
encoding throughout the certification path. 


Update to RFC 3280, Section 4.2.1.7: Subject Alternative Name 
In Section 4.2.1.7, RFC 3280 says: 


When the subjectAltName extension contains a DN in the 
directoryName, the DN MUST be unique for each subject entity 
certified by the one CA as defined by the issuer name field. A CA 
MAY issue more than one certificate with the same DN to the same 
subject entity. 


This block of text is replaced with the following: 


When the subjectAltName extension contains a DN in the 
directoryName, the encoding preference is defined in Section 
4.1.2.4. The DN MUST be unique for each subject entity certified 
by the one CA as defined by the issuer name field. A CA MAY issue 
more than one certificate with the same DN to the same subject 
entity. 


Security Considerations 


The use of consistent encoding for name components will ensure that 
the name constraints specified in [PKIX1] work as expected. 


When strings are mapped from internal representations to visual 
representations, sometimes two different strings will have the same 
or similar visual representations. This can happen for many 
different reasons, including the use of similar glyphs and use of 
composed characters (such as e + ’ equaling U+00E9, the Korean 
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composed characters, and vowels above consonant clusters in certain 
languages). As a result of this situation, people doing visual 
comparisons between to different names may think they are the same 
when in fact they are not. Also, people may mistake one string for 
another. Issuers of certificates and relying parties both need to be 
aware of this situation. 
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Full Copyright Statement 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
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Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 
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